home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2010 April / PCWorld0410.iso / hity wydania / Ubuntu 9.10 PL / karmelkowy-koliberek-desktop-9.10-i386-PL.iso / casper / filesystem.squashfs / usr / share / doc / gconf2-common / TODO < prev   
Encoding:
Text File  |  2009-08-19  |  3.9 KB  |  110 lines
  1. GNOME 1.4 release (must freeze VERY soon)
  2. ===
  3.  
  4. The release with 1.4 is not going to be super-useful for large-scale
  5. installation administration; it's mostly just going to be a
  6. process-transparent way to store settings, limited to single
  7. workstation config files.
  8.  
  9. No more source-incompatible API changes are planned for 1.4 at this
  10. time.
  11.  
  12. API additions
  13. ==
  14.  
  15. * Implement batch gets
  16.  
  17. Other
  18. ==
  19.  
  20. * Maintain documentation
  21.  
  22. * Envisioneering
  23.  
  24. Maybe 1.4
  25. ===
  26.  
  27. * Implement dump/slurp functionality (define XML DTD to represent 
  28.   modifications to the database; augment gconftool to be able to 
  29.   write out the current state of the database in this format, 
  30.   and also apply the changes given in the format)
  31.  
  32. * Make it so that once the first notification of a change in a GConfChangeSet
  33.   is delivered, the other values will be retrieved by gconf_get() and 
  34.   gconf_client_get(), which means a way to invalidate GConfClient
  35.   cached stuff, and doing the setting of all values in the changeset
  36.   before the notifications.
  37.  
  38. * Allow various currently-hardcoded items to be set from environment variables
  39.   or a config file ("home" directory to use, timeout lengths, etc. are 
  40.   some candidates).
  41.  
  42. * "Laptop mode" where GConf avoids touching the disk much
  43.  
  44. * Implement server-side search (Kind of hard to actually implement 
  45.   on the server, at least in any sort of fast way, and 
  46.   all other gconf-using apps will block while the server is searching,
  47.   without some tricks to let the main loop run sometimes, so, dunno.)
  48.  
  49. * Implement a way to get the GConfMetaInfo
  50.  
  51. Future
  52. ===
  53.  
  54. * Berkeley DB backend (note: consider issues surrounding various incompatible 
  55.   versions of DB and historical problems with the upgrade path, cf. 
  56.   RPM and gnome-mime-db)
  57.  
  58. * Performance tuning
  59.  
  60. * Document locking issues for backends (backends should perform
  61.   their own locking, handle concurrency, etc.)
  62.  
  63. * Document which database GConf will write to given multiple 
  64.   writeable databases (i.e. the first one it can write to,
  65.   at the moment, maybe eventually the "database map" will 
  66.   specify which it writes to)
  67.  
  68. * Implement a way for backends to notify gconfd of changes they detect
  69.  
  70. * Implement a "database map"; this would be a tree structure (similar
  71.   in implementation to GConfListeners). Rather than storing listeners
  72.   at the tree nodes, store a list of databases in order, and 
  73.   readability/writability of each database. Create a config file
  74.   (perhaps in the GMarkup XML subset from glib 2.0) for configuring
  75.   the database map. Figure out whether this can entirely replace
  76.   the readable/writable methods from the backend vtable.
  77.   It likely replaces the gconf/path configuration file. (Essentially
  78.   the idea is a database path per key/directory, instead of a 
  79.   global database path, giving administrators more flexibility.)
  80.  
  81.   Also, aliases for paths, and way for apps to install a suggested
  82.   default database alias ("per_display" "per_homedir" etc.)
  83.   (See gconf-list post)
  84.  
  85.   Details to be figured out.
  86.  
  87. * GUI admin tool, and GUI user tool (are these the same?)
  88.  
  89. * Thread support for scalability; may require ORBit thread safety?
  90.   Or a protocol with oneway CORBA methods (client requests a value,
  91.   gconfd calls back when it has the value)
  92.  
  93. * Fix non-default GConfEngines: this means propagating change
  94.   notifications from them to other engines with the same 
  95.   databases. Or maybe instead we should use the mechanism
  96.   used when the same database is in two gconfds (backend 
  97.   notifies us of changes).
  98.  
  99.   Suspect that all notification has to come from the backend,
  100.   this is the only way to get sane behavior if _some_ notification
  101.   comes from the backend. Hmm.
  102.  
  103. * Use a real DTD and a nicer structure for the XML backend format
  104.  
  105. * The design of the client-server architecture is horked, overcomplicating 
  106.   GConf.idl; the client should remember all its state (listeners, etc.), 
  107.   and when the server disappears (we lose the connection to it), the 
  108.   client resends its state; thus eliminating the saved state file 
  109.   and making things more robust.
  110.